home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Shareware Grab Bag
/
Shareware Grab Bag.iso
/
011
/
hidedir.arc
/
HIDDEN.DOC
< prev
next >
Wrap
Text File
|
1984-11-14
|
3KB
|
69 lines
The three files MDSECRET.COM, CDSECRET.COM, and RDSECRET.COM
are trivial programs in size and in complexity, but they
illustrate a technique for utilizing a form of file protection:
locking out sub-directories from all but the determined
knowledgeable user.
The technique involves creating a subdirectory which has the
ASCII DELETE character (07FH) as the first letter of the
subdirectory's name, followed by up to 7 user-specified
characters. MDSECRET (MakeDirectorySECRET) then sets the hidden
flag for the directory entry through the DOS CHMOD function call.
The directory can only be set as the current directory by using
CDSECRET (ChangeDirectorySECRET) and can only be deleted by using
RDSECRET (RemoveDirectorySECRET).
Of course, any super-directory program which shows hidden
files will display the subdirectory names created through
MDSECRET, and a determined user could then use the knowledge of
the directory name to write a program which can access the
subdirectory (just like CDSECRET and RDSECRET do). Without such
a program, the user will not even know the name of the
subdirectory, or even that it exists. If the DELETE character
were not included in the file, the user might try random names
with the CHDIR command, eventually finding one and successfully
accessing it. (Note that a hidden file is just as accessible as
a visible one, if you know its name!) By including the DELETE
character, however, the user will not be able to randomly
generate the subdirectory name from the keyboard, and will not
even be able to issue the CHDIR command from the keyboard for
this subdirectory name.
One important point on the use of the DOS CHMOD function : It
doesn't make sense to try to change the "directory" bit in the
attribute word in a file's directory entry. If the bit is on,
then the file was created as a sub-directory node (MKDIR
function); if the bit is off, then the file is a standard data
file. That much makes good sense. What may not be as obvious is
that you MUST NOT set the directory bit when calling the CHMOD
function, even if the file in question is actually a
subdirectory. DOS apparently checks to see if you have requested
setting the directory bit before it "looks" at the file, and it
exits with an error (#5 -- Access Denied) if you have this bit
set. The only bits which you are allowed to modify (as far as I
know) are the archive bit, the read/only bit, the system file
bit, and the hidden file bit.
If you have any questions about these files, feel free to
contact me through the PCSIG or EMAIL. I don't always access the
PCSIG often to catch messages before they roll off, and this will
get worse in the near future, as I am due to be transferred to a
new city by my employer (God, I hope I can still get to a PC or
clone!).
-Charles Incaprera (73105,1323)
XA 4:
new city by my employer (God, I hope I can still get to a PC or
clone!).
-Charle Incaprera (73105,1323)
XA 4:
new city by my employer (God, I hope I can still get to a PC or
clone!).
-Charle